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1 INDEPENDENT TOOL INTEGRATION 

2 Technical Field 

3 The present invention relates to system administration management in a computer system, and, 

4 in particular, to independent software tool integration. 

5 Background 

6 Software organizations regularly incorporate and integrate software products from other 



7 organizations. However, when two software organizations integrate their software, they normally have 

8 to inform each other of the specific information regarding the software, such as the location of the files, 

9 the possible interactive behavior of the files, and even the software tool definition. Similarly, when a 

1 0 software product is to be improved and upgraded, the base product typically must have concrete 

1 1 knowledge of the add-on products to allow them to function. 

1 2 But increasingly, software organizations that intend to integrate another vendor' s software 

1 3 product may not want to spend the resource to grasp, for example, the software tool definition of the 

1 4 other vendor' s software. Likewise, the other vendor may not want to share the detailed information 

1 5 regarding their software before the tool integration. Accordingly, a need exists for a mechanism to 

1 6 integrate a base product with another product without the need to inform the base product beforehand 

1 7 about the other product's tool definition. 

18 Summary 



1 9 Independent tool integration uses existing mechanisms, software distributor (SD) commands 

20 and a common file directory, to integrate software products, without the need to inform the base 

2 1 product beforehand about the add-on product' s software tool definition. Likewise, the software 

22 products may be automatically updated without the base product having to change. 

23 A method for independent tool integration may include creating a tool definition file that contains 

24 tools to be installed and configured, delivering the tool definition file to a common directory on a server, 
2 5 executing a tool command against the tool definition file to add new tools and to modify existing tools, 
2 6 and delivering the tools defined by the tool definition file to managed nodes using an SD command for 

27 installation and configuration. 

28 Description of the Drawings 
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1 The detailed description refers to the following drawings, in which like numbers refer to like 

2 elements, and in which: 

3 Figure 1 (a) illustrates a computer network system with which the present invention may be 

4 used; 

5 Figures 1(b) and 1(c) compare single-system aware tools and multi-system aware tools; 

6 Figure 2 illustrates the relationships between the user, role, node, tool and authorization obj ects; 

7 Figure 3 is a block diagram of an exemplary server used to implement the present invention; 

8 and 

9 Figure 4 is a flow chart of a method for independent tool integration in the SCM module. 

10 Detailed Description 

1 1 A service control manager (SCM) module multiplies system administration effectiveness by 

1 2 distributing the effects of existing tools efficiently across managed servers. The phrase "service control 

1 3 manager" is intended as a label only, and different labels can be used to describe modules or other 

14 entities having the same or similar functions. 

15 In the SCM domain, the managed servers (systems) are referred to as "managed nodes" or 



1 6 simply as "nodes". SCM node groups are collections of nodes in the SCM module. They may have 

1 7 overlapping memberships, such that a single node may be a member of more than one group. The 

1 8 grouping mechanism may allow flexible partitioning of the SCM module so that users may use it to 

19 reflect the way nodes are already grouped in their environment. 

20 Figure 1 illustrates a computer network system with which the present invention may be used. 

2 1 The network system includes an SCM 1 1 0 running on a Central Management Server (CMS) 1 00 and 

22 one or more nodes 1 30 or node groups 132 managed by the SCM 1 10. The one or more nodes 130 

23 andnodegroups 132 make up an SCM cluster 140. Alternatively, the CMS 100 may be part of the 

24 SCM cluster 140. See ServiceControl Manager Technical Reference, HP® part number: B8339- 

25 90019 , available from Hewlett-Packard Company, Palo Alto, CA., which is hereby incorporated by 

26 reference and which is also accessible at <http://www.software.hp.com/products/scmgr> , for a more 

27 detailed description of the SCM 1 1 0. 
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1 The CMS 1 00 can be implemented with, for example, an HP-UX 1 1 .x server running the SCM 

2 110 software. The CMS 1 00 includes a memory 1 02, a secondary storage device (not shown), a 

3 processor 1 08, an input device (not shown), a display device (not shown), and an output device (not 

4 shown). The memory 1 02 may include computer readable media, RAM or similar types of memory, 

5 and it may store one or more applications for execution by processor 1 08, including the SCM 110 

6 software. The secondary storage device may include computer readable media, a hard disk drive, 

7 floppy disk drive, CD-ROM drive, or other types of non- volatile data storage. The processor 1 08 

8 executes the SCM software and other application(s), which are stored in memory or secondary 

9 storage, or received from the Internet or other network 1 1 6. The input device may include any device 

1 0 for entering data into the CMS 1 00, such as a keyboard, key pad, cursor-control device, touch-screen 

1 1 (possibly with a stylus), or microphone. The display device may include any type of device for 

1 2 presenting a visual image, such as, for example, a computer monitor, flat-screen display, or display 

1 3 panel. The output device may include any type of device for presenting data in hard copy format, such 

14 as a printer, and other types of output devices include speakers or any device for providing data in 

1 5 audio form. The CMS 1 00 can possibly include multiple input devices, output devices, and display 

16 devices. 

17 The CMS 100 itself may be required to be a managed node, so that multi-system aware 

1 8 (MSA) tools may be invoked on the CMS . All other nodes 1 30 may need to be explicitly added to 

19 the SCM cluster 140. 

20 Generally, the SCM 1 1 0 supports managing a single SCM cluster 1 40 from a single CMS 1 00. 

2 1 All tasks performed on the SCM cluster 1 40 are initiated on the CMS 1 00 either directly or remotely, 

22 for example, by reaching the CMS 1 00 via a web connection 114. Therefore, the workstation 1 20 at 

23 which a user sits only needs a web connection 1 1 4 over a network 1 1 6, such as the Internet or other 

24 type of computer network, to the CMS 1 00 in order to perform tasks on the SCM cluster 1 40. The 

25 CMS 1 00 preferably also includes a centralized data repository 1 04 for the SCM cluster 1 40, a web 

26 server 1 1 2 that allows web access to the SCM 1 1 0 and a depot 1 06 that includes products used in the 

27 configuring of nodes 130. A user interface may only run on the CMS 100, and no other node 130 in 

28 the SCM module may execute remote tasks, access the repository 1 04, or any other SCM operations. 
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1 Although the CMS 100 is depicted with various components, one skilled in the art will 

2 appreciated that this server can contain additional or different components. In addition, although 

3 aspects of an implementation consistent with the present invention are described as being stored in 

4 memory, one skilled in the art will appreciated that these aspects can also be stored on or read from 

5 other types of computer program products or computer-readable media, such as secondary storage 

6 devices, including hard disks, floppy disks, or CD-ROM; a carrier wave from the Internet or other 

7 network; or other forms of RAM or ROM. The computer-readable media may include instructions 

8 for controlling the CMS 100 to perform a particular method. 

9 A central part of the SCM module 1 1 0 is the ability to execute various management commands 

10 or applications on the one or more nodes simultaneously. The commands or applications may need to 

1 1 be encapsulated with an SCM tool, which is typically used to copy files and/or execute commands on 

12 the target nodes 130. The SCM tool may run simple commands such as bdf ( 1 ) or mount ( 1 M), launch 

1 3 single system interactive applications such as System Administration Manager (SAM) or Glance, launch 

1 4 multi-system aware applications such as Ignite/UX or Software Distributor (SD), or perform other 

1 5 functions. The tool may be defined using an SCM tool definition language through either a command 

16 line interface (CLI) or an SCM-provided graphical user interface (GUI). 

1 7 There are two general types of tools: single-system aware (SSA) tools and multi-system aware 

1 8 (MSA) tools. SSA tools, illustrated in Figure 1 (b), may run on a node 130 and may only affect the 

1 9 operation of that node 1 30. To run SSA tools on multiple target nodes 1 30, the SCM module 1 1 0 may 

20 execute the tools on each target node 130. In addition to executing commands or launching 

2 1 applications, SSA tools may copy files from the CMS 1 00 to the target nodes 1 30. Files may only be 

22 copied from the CMS 1 00 to the managed nodes 1 3 0 in this exemplary embodiment, not from the 

23 nodes 130 back to the CMS 100. 

24 MSA tools, illustrated in Figure 1 (c), may run on a single node 1 30 but may be able to operate 

25 on multiple other nodes 1 30. MSA tools are applications that execute on a single node but can detect 

26 and contact other nodes to accomplish their work and this contact is out of the control of the SCM 

27 module 1 10. This type of application may need to have a list of nodes 130 passed as an argument at 
2 8 runtime. A node 1 3 0 where the application will execute may need to be specified at tool creation time, 
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1 not at runtime. The target nodes 130 selected by the user may be passed to an MSA tool via a target 

2 environment variable that contains a target node list for the MSA tools. MSA tools may not copy files 

3 to either the manager node 1 00 or to the target nodes 1 30 in this exemplary embodiment. Therefore, 

4 an execution command string may be required for MSA tools. 

5 An SCM user may be a user that is known to the SCM module 1 1 0 and has some privileges 

6 and/or management roles. An SCM role, which is an expression of intent and a collection of tools for 

7 accomplishing that intent, typically defines what the user is able to do on the associated nodes 1 3 0 or 

8 node groups 132, e.g., whether a user may run a tool on a node 130. Typically, in order to start the 

9 SCM module 1 1 0 or execute any SCM tools, the user may need to be added to the SCM module 1 1 0 

□ 10 and authorized either via the GUI or the command line interface (CLI). All SCM module 1 10 
i g 11 operations may be authorized based on the user's SCM authorization configuration, and/or whether or 
vjj 12 not the user has been granted SCM trusted user privilege. 

[7! 13 The SCM user may, depending upon the roles assigned, manage systems via the SCM module 

r y 14 1 1 0. In addition, the user may examine the SCM module log, and scan the group, node, and role 

□ 15 configurations. When the SCM user runs a tool, the result may be an SCM task. The SCM module 

□ 16 110 typically assigns a task identifier for every task after it has been defined and before it is run on any 
P 17 target nodes 130. This identifier may be used to track the task and to look up information later about 
■ ** 18 the task in an SCM central log. 

19 An SCM trusted user is an SCM user responsible for the configuration and general 

20 administration of the SCM module 110. The trusted user is typically a manager or a supervisor of a 

2 1 group of administrators whom a company trusts, or another trusted individual . Entrusted with the 

22 highest authority, the trusted user may execute any system management task with all of the nodes 

23 (machines) managed by the SCM module 1 10. The capabilities of the trusted user include, for 

24 example, one or more of the following: creating or modifying a user 5 s security profile; adding, modifying 

25 or deleting a node or node group; role modification; tool modification; and tool authorization. The 

26 granting of these privileges implies a trust that the user is responsible for configuring and maintaining the 

27 overall structure of the SCM module 110. 

28 An SCM authorization model supports the notion of assigning to users the ability to run a set 



HP No. 10007487 




1 of tools on a set of nodes. An authorization object is an association that links a user to a role on either 

2 a node or a node group. Each role may have one or more tools and each tool may belong to one or 

3 more roles. When users are given the authority to perform some limited set of functionality on one or 

4 more nodes, the authorization is done based upon roles and not on tools. The role allows the sum total 

5 of functionality represented by all the tools to be divided into logical sets that correspond to the 

6 responsibilities that would be given to the various administrators. Accordingly, there are different roles 

7 that may be configured and assigned with authorization. For example, a backup administrator with a 

8 "backup" role may contain tools that perform backups, manage scheduled backups, view backup 

9 status, and other backup functions. On the other hand, a database administrator with a "database" role 

1 0 may have a different set of tools. When a user attempts to run a tool on a node, the user may need to 

11 be checked to determine if the user is authorized to fulfill a certain role on the node and if that role 

1 2 contains the tool. Once a user is assigned a role, the user may be given access to any newly created 

1 3 tools that are later added to the role. In the example given above, the backup administrator may be 

1 4 assigned the "backup" role for a group of systems that run a specific application. When new backup 

1 5 tools are created and added to the "backup" role, the backup administrator may immediately be given 

1 6 access to the new tools on the systems. 

1 7 Figure 2 illustrates the relationships between the user 2 1 0, role 220, node 1 3 0, tool 240, and 

1 8 authorization 250 objects. User objects 210 represent users 210, role objects 220 represent roles 

1 9 220, node objects 130 represent nodes 130, tool objects 240 represent tools 240, and authorization 

20 objects 250 represent authorizations 250. However, for purposes of this application, these terms are 

2 1 used interchangeably. Each authorization object 250 links a single user object 2 1 0 to a single role 

22 object 220 and to a single node object 130 (or a node group object 132). Each role object 220 may 

23 correspond to one or more tool objects 240, and each tool object 240 may correspond to one or more 

24 role objects 220. Each user obj ect 2 1 0 may be assigned multiple authorizations 250, as may each role 

25 object 220 and each node object 1 30. For example, Role 1 may contain Tools 1 -N, and User 1 may 

26 be assigned Roles 1-M by the authorization model on Node 1. Consequently, User 1 may run Tools 

27 1 -N on Node 1 , based upon the role assigned, Role 1 . 

28 Table 1 illustrates an example of a data structure for assigning tools 240 and commands 
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1 specified in the tools 240 to different roles 220. Table 2 illustrates an example of a data structure for 

2 assigning the roles 220 to different users 210. 
3 
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,p 15 

|S 16 Table 2 

1 8 Although Figure 2 shows a node authorization, a similar structure exists for a node group 1 32 

1 9 authorization. The SCM authorization model may be deployed by using node group 1 32 authorizations 

20 more often than node 130 authorizations. This model makes adding new nodes simpler because by 

21 addinganode 130 to an existing group 132, any authorizations associated with the group 132maybe 

22 inherited at run-time by the node 1 30. 

23 The authorization model for determining if a user may execute a tool 240 on a set of nodes 1 3 0 

24 may be defined by an "all or none" model. Therefore, the user 2 1 0 must have a valid authentication 

25 association for each target node 1 30 to execute the tool 240. If authorization does not exist for even 

26 one of the nodes 130, the tool execution fails. 

27 The SCM module 1 1 0 may also include security features to secure transactions that transmit 
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across the network. All network transactions may be digitally signed using a public or private key pair. 
The recipient of network transmissions may be assured of who the transmission came from and that the 
data was not altered in the transmission. A hostile party on the network may be able view the 
transactions, but may not counterfeit or alter them. 

Referring to Figure 3, the CMS 1 00 may include a domain manager 330, a log manager 334, 
and a distributed task facility (DTF) 240. The domain manager 330 is the "brain" of SCM module 1 1 0 
and may be connected to the repository 104 for storage of the definitions of all the objects. 

The DTF 340 may execute tasks by passing the task definitions and information to agents 
running on the managed nodes 1 30. The DTF 340 is the "heart" of all task execution activity in that 
all of the execution steps must go through the DTF 340. The DTF 340 typically obtains an authorized 
runnable tool from the user 210 through a client, distributes the tool execution across multiple nodes 
130, and returns execution results to the clients and to the user 210. 

An integral part of the SCM functionality may be the ability to record and maintain a history of 
events, by logging both SCM configuration changes and task execution events through the log manager 
334. The log manager 334 may manage a log file andtake log requests from the DTF 340 and write 
the requests to the SCM log file. SCM configuration changes may include adding, modifying and 
deleting users and nodes in the SCM module 1 1 o/and creating, modifying and deleting node groups 
1 32 and tools 240. An example of task execution events may include details and intermediate events 
associated with the running of a tool 240. An/example of task execution is described in United States 
patent application of Lister, Sanchez, Drees, and Finz, entitled "Service Control Manager Tool 
Execution", and filed on the same day herewith, which is incorporated herein by reference. The details 
that are logged may include the identity of the user 2 1 0 who launched the task, the actual tool and 
command line with arguments, and the list of target nodes 1 30. The intermediate events that are logged 
may include the beginning of a tasK on a managed node 130, and exceptions that occur in attempting 
to run a tool 240 on a node 1 30,/and the final result, if any, of the task. The exit code, and standard 
output (stdout) and standard/error output (stderr), if they exist, may also be logged. 

A security manager 332, which is a subsection of the domain manager 330, typically guards 
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1 the system security by checking whether the user 2 1 0 is authorized to run the tool 240 on all of the 

2 nodes 1 30 requested, i.e., whether the user 2 1 0 is assigned the roles 220 associated with the tool 240 

3 on all of the nodes 130. 

4 A tool 240 may be started in an SCM environment, which is the memory set aside for the tool 

5 240 to look up attribute values. When launching MSA applications, the SCM environment may be 

6 extended to pass additional information by providing additional environment variables. For example, 

7 mxuser is a user environment variable that contains the login name or user identification of the user 210 

8 executing the tool 240 ; mxtask ID is a task environment variable that contains the DTF task ID and 

9 uniquely names a tool execution instance; mxtool is a tool environment variable that contains the name 

1 0 of the tool 240 that executed this specific executable; mxtargets is a target environment variable that 

1 1 contains the application' s target node list for MSA applications, the list of node names may be space- 

1 2 delimited and sorted in a lexicographic order; mxcms is an environment variable that contains the host 

1 3 name of the Central Management Station; and mxrepository is an environment variable that contains 

14 the hostname ofthe system containing the SCMrepository 104. When auser 210 with authorization 

1 5 to nodes 1-5 launches a tool 240, the SCM module 110 determines an identity of the user and 

1 6 establishes environment variables that contain attribute value pairs, so that only nodes 1 -5 can be 

1 7 accessed by this user 2 1 0. Accordingly, the behavior of these applications is different when they run 

1 8 stand-alone and when they run in the SCM environment, where they have to follow the rules set by the 

1 9 SCM module 110. If the user 210 tries to access resources outside that domain, the attempt will be 

20 blocked and an error message returned. 

2 1 Applications may be integrated into the SCM environment by creating an SCM tool 240 for 

22 them. This tool 240 may have a wrapper script, a file based textual directive provided in an Unix shell 

23 for interpretation and execution, to process any input parameters and run the application. The 

24 application software may need to be pre-installed on the target nodes 130. Accordingly, when two 
2 5 software organizations integrates their software, they typically have to inform each other ofthe specific 

26 information regarding the software, such as the location of the files, the possible interactive behavior of 

27 the files, and even the software tool definition. Similarly, when a software product is to be improved 

28 and upgraded, the base product typically must have concrete knowledge of the add-on products to 
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1 allow them to function. 

2 Independent tool integration uses existing mechanisms, software distributor (SD) commands 

3 and a common file directory, to integrate software products without the need to inform the base product 

4 beforehand about the new product' s software tool definition. The software products may also be 

5 automatically updated without the base product having to change. SD is the HP-UX administration 

6 toolset used to deliver and maintain HP-UX operating systems and layered software applications. SD 

7 may allow central IT departments to control an associated software environment. It also improves 

8 administrator productivity by automating software distribution. 

$. U \> A ^ There may be three parts to independenftool integration. The first part is for the new products 

t O 10 to be integrated to create their own tool definition file and provide software product' s tools 240. An 

}%i 11 example of a tool definition is described in United States patent application of Lister , Sanchez, Drees, 

| « 12 and Finz, entitled "Service Control Manager Tool Definition", and filed on the same day herewith, 

| -H 13 which is incorporated herein by reference. The tool definition file may define software tools 240 to be 

i _ 14 executed by the users 210. Only then CMS 1 00 needs to know the tool definitions. Tool definitions 

] p 15 may be added or modified by calling the mxtool command. To create the tool definition file, the tools 

16 240, either SSA tools or MSA tools, may need to provide server software, referred to as server 

1 7 filesets, to be installed on the QMS 1 00. The server filesets are any filesets in the new products that 

1 8 need to be installed on the CMS 1 00 for the tool integration to process. The software product' s tools 

1 9 240 may be a set of software commands and files that may be delivered to the managed nodes 130 

20 (described later in part th/ee). 

2 1 After the tool definition file is created, it may be delivered to a common directory, such as 

22 /var/opt/mx/tools, on the CMS 1 00 using, for example, swinstall; /var/opt/mx/tools is the directory 

23 where the tool definition may be delivered to in order to be automatically processed, while swinstall is 

24 part of the SD toolset to perform software installations. 

25 The second part of independent tool integration involves determining whether the mxtool 

26 command, typically delivered by the SCM software, exists on the CMS 1 00. If the mxtool is on the 

27 CMS 1 00 and the CMS 1 00 has been initialized, the mxtool command may first be executed against 
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1 the tool definition file to add the new tools 240 to the tool definition file. If there are modifications to 

2 be made to the previously delivered tools 240, the mxtool command may be executed again to modify 

3 the old tools 240. The two steps may be required because the mxtool command may be run with either 

4 an -a option (add) or an -m option (modify), and "add" may not alter any existing tools 240, while 

5 "modify" may not add any new tools 240 from the tool definition file. For example, a user 2 1 0 delivers 

6 a tool definition file in January and installed it on the CMS 1 00. In March, the user 2 1 0 delivers a new 

7 tool definition file, purporting to modify old tool definitions and to add new tool definitions to the original 

8 tool definition. To integrate the new tools 240 and the modifications of the old tools 240, the user 210 

9 may need to first run the mxtool command with the -a option to add the new tools 240, then run the 

10 mxtool again with the -m option to ensure that modifications, if any, are properly made. 

1 1 If either the mxtool command does not exist or the CMS 1 00 is not initialized, then when a 

1 2 setup command, referred to as mxsetup, is run to initialize the CMS 1 00, the tool definition files in the 

1 3 /var/opt/mx/tools directory may be automatically processed. The mxsetup command may perform a 

1 4 series of steps to initialize and configure the CMS software. One of the final steps of this series of steps 

15 may be to use the mxtool command with the -a option to process each of the files in the 

16 /var/opt/mx/tools directory. 

1 7 The tool 240 may need to provide a corresponding unconfigure script, which may call the 

1 8 mxtool command for the list of tools 240, and remove the tool definition files from the directory. The 

1 9 unconfigure script may be a list of commands run by the SD software removal tool, referred to as 

20 swremove. One of the commands in this list may be mxtool command with an -r option, to remove the 

2 1 tool definitions. 

22 The third part of independent tool integration is to deliver the new software product' s tools 240 

23 onto all of the managed nodes 1 30 for installation and configuration. This part may be necessary only 

24 if the new product requires that a portion of its software exists on the managed nodes 130. This 

25 process may be accomplished using software copying or packaging tools, referred to as swcopy or 

26 swpackage, respectively. 

27 As a first step of this process, the software product' s tools 240 may be copied or packaged 
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1 into one or more known software depot directory locations, such as /var/opt/mx/depot 10 and 

2 /var/opt/mx/depot 1 1 , which may be automatically created by mxsetup during initialization. The tools 

3 240 may need to provide agent software, referred to as agent filesets, to be installed on the managed 

4 nodes 1 3 0 for the integration to proceed. In the next step, the SD command, swinstall, may be used 

5 to distribute the agent filesets to all of the managed nodes 1 30 to be installed and configured. For some 

6 tools 240, where the supporting software only needs to be installed on the CMS 1 00, this step is not 

7 necessary. 

8 If the tools 240 require any software synchronization between the CMS 1 00 and the managed 

9 nodes 1 3 0, a synchronization software may be delivered in filesets, referred to as agent configure 

1 0 filesets. The configure script that is delivered as part of this fileset may perform any setup steps that are 

1 1 required for this synchronization. For example, if a file on the managed nodes 130 needs to have the 

12 CMS's hostname written to it, the configure script may perform that action. 

1 3 During update, the integration may follow the same steps as the integration during initial setup. 

14 A new version of the new product may be required to be installed on the CMS 1 00. The new product 

1 5 being updated may also provide a new version of its agent fileset for any of the managed nodes 130, 

1 6 and may provide a new version of its agent configure fileset to perform any new synchronization actions. 

1 7 As part of its configure script, the new product' s software that is installed on the CMS 1 00 may run 

18 the mxtool command with the -a and -m options to add and modify new and existing tools 240. This 

1 9 new product update may be independent of any SCM base product. If the new product also includes 

20 an agent fileset, then that fileset may need to be reinstalled on the managed nodes 130. Finally, if an 

2 1 agent configure fileset needs to be installed, it may be placed into the /var/opt/mx/depot 1 0 and 

22 /var/opt/mx/depot 1 1 depots, and may be reinstalled on the managed nodes 130. 

2 3 Figure 4 illustrates a method for independent tool integration in the SCM module. This method 

24 may be implemented, for example, in software modules for execution by processor 1 08. First, the new 

25 products to be integrated may create a tool definition file that define tools 240 to be installed and 

26 configured, step 4 10. This may involve installing server filesets on the server, i.e., CMS 100,step415. 

27 The new products may also provide software product's tools 240 to be delivered later to the managed 

28 nodes 130, step 418. Next, the tool definition file may be delivered to a common directory, such as 
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1 /var/opt/mx/tools, on the CMS 100 using, for example, swinstall, step 420. 

2 In the next step, the SCM module 1 1 0 may determine whether the server 1 00 has been 

3 initialized and whether the mxtool command exists on the CMS 1 00, step 430. If yes, the mxtool 

4 command may first be executed against the tool definition file, step 440, to add the new tools 240 to 

5 the tool definition file, step 442 . If there are modifications to be made to the previously delivered tools 

6 240, the mxtool may be executed again, step 440, to modify the old tools 240, step 444. 

7 If either the mxtool command does not exist or the CMS 1 00 is not initialized, then when the 

8 mxsetup command is run to initialize the CMS 1 00, the tool definition files in the /var/opt/mx/tools 

9 directory may be automatically processed, step 450, which may include adding new tools 240 to the 

[q 10 tool definition file, step 452. 

10 

j !i 1 1 In the final step of the independent tool integration, the software product ' s tools 240 may be 

13 12 delivered to the managed nodes 1 3 0 using SD commands, step 460 . The first part of the process 

13 involves copying or packaging the software product' s tools 240 into two or more known software 

[ 14 depot directories, such as /var/opt/mx/depot 1 0 and /var/opt/mx/depot 1 1 , using either the swcopy or 

j p 15 swpackage software distributor commands, respectively, step 462. The tools 240 may provide the 

□ 

|f| 16 agent filesets to be installed on the managed nodes 130, step 464. Then, the SD commands may be 

!3 

j ™ 17 used to distribute the agent filesets to all of the managed nodes 1 3 0 to be installed and configured, step 

1 8 466. During update, if the new product also includes an agent fileset, then that fileset may need to be 

19 reinstalled on the managed nodes 130, step 468. 

20 If the tools 240 require any software synchronization between the CMS 1 00 and the managed 

21 nodes 130, a synchronization software may be delivered in the agent configure fileset, step 470. 

22 Finally, during update, if an agent configure fileset needs to be installed, it may be placed into the 

23 /var/opt/mx/depot 1 0 and /var/opt/mx/depot 1 1 depots on the CMS 1 00, and may be reinstalled on 

24 the managed nodes 130, step 472. 

2 5 While the present invention has been described in connection with an exemplary embodiment, 

26 it will be understood that many modifications will be readily apparent to those skilled in the art, and this 

27 application is intended to cover any variations thereof. 
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